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Monterey,  CA  93943 

ABSTRACT 

We  present  a  language-independent  semantic  model  of  the  process  of  combining 
changes  to  programs.  This  model  extends  the  domains  used  in  denotational  semantics 
(complete  partial  orders)  to  Boolean  algebras,  and  represents  incompatible 
modifications  as  well  as  compatible  extensions.  The  model  is  used  to  define  the 
intended  semantics  of  change  merging  operations  on  programs  and  to  establish  some 
general  properties  of  software  merging.  We  determine  conditions  under  which  changes 
to  subprograms  of  a  software  system  can  be  merged  independently  and  illustrate  cases 
where  this  is  not  possible. 

Keywords:  software  change  merging,  semantics,  domains,  software  maintenance. 

1.    Introduction 

Practical  software  systems  have  many  different  versions,  all  of  which  are  con- 
stantly changing  in  response  to  changes  in  user  needs,  the  operating  environment,  and 
the  discovery  of  faults.  Such  changes  often  have  to  be  developed  concurrently  and 
then  combined,  or  the  "same"  change  has  to  be  applied  to  several  different  versions  of 
the  system.  We  call  the  process  of  combining  several  changes  software  change  merg- 
ing. Tool  support  for  this  process  is  desirable,  possibly  in  the  form  of  automated 
assistant  to  a  designer  [22].  However,  a  production-quality  tool  should  always  produce 
either  a  correct  result  or  an  indication  of  failure  together  with  diagnostic  information. 
A  clear  and  precise  model  of  change  merging  is  needed  to  build  such  tools  and  to 
demonstrate  that  they  achieve  the  required  degree  of  "correctness". 

This  paper  provides  such  a  model  and  determines  some  of  its  characteristics. 
Since  our  goal  is  to  formulate  a  language-independent  definition  of  the  requirements 
for  change  merging,  we  focus  on  merging  changes  to  the  meaning  of  a  program  (rather 
than  changes  to  the  concrete  representation  of  a  program).  This  is  only  part  of  the 
problem:  a  practical  tool  must  operate  on  concrete  representations  of  programs  and 
produce  a  concrete  program  whose  meaning  agrees  with  our  model  unless  it  explicitly 
reports  failure.  Methods  for  change  merging  that  operate  on  concrete  representations 
of  programs  are  outside  the  scope  of  this  paper.  A  concrete  method  for  change  merg- 
ing that  is  based  directly  on  a  special  case  of  the  models  presented  here  can  be  found 
in  [2]. 
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We  achieve  language-independence  via  the  constructions  used  in  denotational 
semantics  to  define  the  meanings  of  programming  languages.  The  domains  used  in 
traditional  denotational  semantics  do  not  have  enough  structure  to  provide  a  general 
definition  of  change  merging.  The  main  contribution  of  this  paper  is  a  set  of  extended 
domain  constructions  that  can  support  such  a  definition  and  a  formalization  of  the 
notion  of  a  semantic  conflict  between  changes.  Since  exact  merging  is  not  computable 
[1],  the  set  of  inputs  for  which  a  merging  tool  reports  a  failure  and  the  semantic  merg- 
ing model  produces  a  conflict-free  result  is  one  criterion  for  comparing  different  merg- 
ing tools.  We  also  explore  some  semantic  limitations  on  merging  that  are  related  to 
functional  decomposition. 

Section  2  reviews  some  relevant  previous  work.  Section  3  presents  the  construc- 
tion of  semantic  domains  appropriate  for  program  merging,  first  reviewing  the  basic 
properties  of  approximation  lattices,  then  extending  these  lattices  to  Boolean  algebras 
and  showing  the  relation  to  Browerian  algebras.  The  purpose  of  these  structures  is  to 
extend  the  ordinary  semantic  domains  to  include  improper  values  representing  combi- 
nations of  incompatible  design  decisions.  This  lets  us  model  software  merging  as  a 
total  operation  on  these  extended  domains,  and  enables  the  change  merging  in  the 
domain  of  program  meanings  to  identify  semantic  conflicts  in  cases  where  changes 
cannot  be  consistently  combined.  Section  4  uses  the  algebraic  structures  developed  in 
Section  3  to  support  a  formal  definition  of  an  ideal  operation  for  combining  the  seman- 
tics of  software  modifications,  and  determines  some  of  the  properties  of  this  formal 
model.    Section  5  presents  some  conclusions  and  directions  for  future  work. 

2.    Previous  Work 

The  problem  of  combining  two  versions  of  a  functional  program  was  formalized 
as  constructing  the  least  common  extension  of  two  partial  functions  in  [1].  This  is  a 
simplified  version  of  the  problem  considered  in  this  paper,  which  includes  incompati- 
ble modifications  as  well  as  compatible  extensions.  The  intended  semantics  of  merg- 
ing compatible  extensions  was  expressed  using  lattices  and  the  approximation  ordering 
l  used  in  traditional  approaches  to  denotational  semantics  of  programming  languages 
[23,25]. 

These  lattice  structures  were  refined  into  larger  Boolean  algebras  to  model  incom- 
patible changes  via  a  suitable  difference  operation  in  [2].  The  idea  behind  the  domain 
construction  was  sketched  briefly,  and  was  limited  to  primitive  domains,  cross  pro- 
ducts, and  a  rough  approximation  to  function  spaces  that  was  limited  to  additive  func- 
tions (see  [25]  p.  105).  The  current  paper  repairs  the  deficiencies  in  the  Boolean  func- 
tion space  construction,  and  introduces  Boolean  versions  of  an  extended  sum  construc- 
tor, two  of  the  three  main  power  domain  constructors,  and  recursively  defined  domains 
(solutions  to  reflexive  domain  equations).  The  current  paper  also  formalizes  the  idea 
of  semantic  conflicts,  and  explores  properties  of  the  change  merging  model  related  to 
functional  composition  as  well  as  the  conditions  under  which  the  result  of  a  set  of 
changes  is  independent  of  the  order  in  which  they  are  applied.  We  also  show  that 
change  merging  does  not  preserve  monotonicity  (or  computability). 


We  view  changes  as  transformations  from  versions  to  versions  as  was  done  in  [2], 
and  prove  a  minimality  property  suggested  there.  Change  transformations  have  been 
developed  in  a  different  way  in  [20]. 

This  paper  characterizes  the  intended  semantics  of  change  merging  but  does  not 
address  concrete  methods  for  change  merging.  Specific  methods  for  change  merging 
are  briefly  surveyed  here  (see  [5]  for  more  information).  The  first  semantically  based 
methods  for  combining  two  versions  of  a  functional  program  were  given  in  [1].  A 
method  for  merging  versions  of  PROLOG  programs  is  [24].  An  approach  to  combin- 
ing both  modifications  and  compatible  extensions  to  while-programs  based  on  data 
flow  analysis  and  operations  on  program  dependency  graphs  is  described  by  Horowitz, 
Prins,  and  Reps  [12],  and  this  approach  was  subsequently  improved  [26].  Another 
method  for  solving  this  problem  that  produces  fewer  spurious  conflict  reports  is 
described  in  [2].  A  method  for  merging  changes  to  prototypes  with  concurrent  actions 
and  hard  real-time  constraints  is  described  in  [7]. 

3.    Semantic  Domains  for  Software  Merging 

This  section  explores  semantic  domains  that  can  support  change  merging  opera- 
tions. A  difference  operation  is  desirable  for  this  purpose,  and  at  least  a  pseudo- 
difference  operation  seems  to  be  needed.  Since  the  domains  commonly  used  in  deno- 
tational  semantics  do  not  in  general  provide  such  operations,  we  explore  refinements  to 
those  domains. 

Section  3.1  reviews  some  relevant  properties  of  the  domains  used  in  denotational 
semantics.  Section  3.2  presents  a  construction  that  extends  a  class  of  complete  partial 
orders  commonly  used  in  denotational  semantics  to  atomic  Boolean  algebras  (which 
provide  a  difference  operation).  Section  3.3  explores  the  relation  of  this  effort  to 
Browerian  algebras  (which  provide  a  pseudo-difference  operation). 

Every  atomic  Boolean  algebra  is  a  Boolean  algebra  as  well  as  a  lattice,  and 
satisfies  all  of  the  usual  laws  of  Boolean  algebras.  It  is  possible  to  understand  most  of 
the  later  parts  of  this  paper  in  terms  of  the  interpretations  for  the  Boolean  operations 
summarized  in  Fig.  1,  without  knowledge  of  the  special  properties  of  the  atomic 
Boolean  algebras  constructed  in  Section  3.2,  although  some  parts  of  the  proofs  depend 
on  these  properties. 

3.1.   Lattices  and  Approximation  Orderings 

The  domains  used  in  denotational  semantics  are  all  partially  ordered  sets  with  an 
approximation  ordering  Z  .  Typical  domains  are  special  kinds  of  function  spaces 
whose  elements  represent  meanings  of  programs.  An  approximation  f  Q  g  means  that 
g  is  a  compatible  extension  of  /:  g  agrees  with  /  whenever  /  is  defined,  and  g  may 
be  defined  in  cases  where  /  is  not.  Our  model  of  change  merging  uses  lattices  that 
are  special  cases  of  this  kind  of  structure. 

A  lattice  is  a  partially  ordered  set  that  contains  least  upper  bounds  and  greatest 
lower  bounds  for  all  finite  subsets.  Lattices  have  a  least  upper  bound  operation  lj  ,  a 
greatest  lower  bound  operation  n  ,  a  least  element  i ,  and  a  greatest  element  t  . 


All  of  the  features  of  a  lattice  are  relevant  to  change  merging.  The  least  upper 
bound  merges  all  of  the  information  contained  in  two  elements.  The  greatest  lower 
bound  extracts  the  information  common  to  both  elements.  The  least  element  l 
denotes  the  absence  of  information,  and  is  used  together  with  n  to  indicate  that  two 
elements  do  not  contain  any  common  information.  The  greatest  element  7  represents 
an  inconsistency:  the  result  of  merging  (all  possible)  incompatible  information. 

Denotational  semantics  was  originally  formulated  using  special  kinds  of  lattices. 
Later  formulations  were  recast  in  terms  of  epos  (complete  partial  orders)  that  are  sub- 
sets of  the  original  lattices.  This  was  done  partially  to  avoid  overconstrained  elements 
such  as  T  ,  which  do  not  have  a  natural  interpretation  for  individual  programs.  In  the 
context  of  change  merging,  overconstrained  elements  represent  conflicts  between 
semantically  incompatible  changes.  Since  independently  developed  changes  can  easily 
be  semantically  incompatible,  overconstrained  elements  have  natural  interpretations  in 
our  context. 

Since  lattice  operations  are  applied  to  functions  independently  at  each  point,  over- 
constrained  elements  may  be  useful  for  localizing  semantic  incompatibilities  and  diag- 
nosing their  causes.    A  simple  example  illustrates  the  idea. 

[  1 ,  1.  2,  3]  Li  [4,  1.   i  ,  5]  =  [4.  1.  2.  3  _  5] 

Here  we  use  sequences  of  length  four  as  idealized  finite  examples  of  semantic  func- 
tions representing  meanings  of  programs.  Tne  least  upper  bound  merges  the  informa- 
tion in  the  two  functions  to  produce  a  third,  which  has  normal  data  values  in  the  first 
three  positions  and  an  overconstrained  value  in  the  fourth.  The  presence  of  the  over- 
constrained  value  indicates  a  semantic  conflict,  its  location  indicates  the  part  of  the 
input  space  that  is  affected  (the  fourth  value  in  the  index  set  for  the  sequence),  and  the 
overconstrained  value  itself  indicates  the  nature  of  the  conflict  (the  same  output  has 
been  simultaneously  constrained  to  have  two  different  and  incompatible  values,  3  and 
5).    Thus  we  have  a  semantic  model  for  an  idealized  error  reporting  facility. 

It  is  of  course  much  easier  to  merge  the  semantics  of  programs  than  it  is  to 
materialize  the  concrete  programs  corresponding  to  the  merged  semantics,  and  the 
problem  of  diagnosing  and  locating  conflicts  between  changes  is  far  from  being  solved 
in  practice.  However,  it  does  help  to  have  a  clear  idea  of  an  idealized  goal  for  error 
reporting.  A  partial  change  merging  method  that  can  in  some  cases  derive  a  program 
representation  with  overconstrained  program  elements  in  the  parts  of  the  program  that 
produce  semantic  conflicts  is  described  in  [2].  Representations  of  such  overconstrained 
program  elements  are  detectable  by  syntactic  operations  and  could  be  used  as  a  basis 
for  generating  concrete  error  messages. 

3.2.   Atomic  Boolean  Algebras 

To  model  incompatible  changes  to  the  semantics  of  a  program,  we  need  a 
difference  operation  to  describe  the  information  that  was  removed  from  a  software 
object.  If  we  treat  the  partial  functions  computed  by  our  programs  as  sets  of  pairs, 
then  the  set  difference  operation  captures  this  idea  for  first-order  functions.  Together 
with  q  ,  u,  n  and  set  complementation  this  structure  forms  a  Boolean  algebra,  which 
is  a  simple  and  typical  example  of  the  extended  semantic  domains  we  will  be  using. 


Boolean  algebras  provide  natural  generalizations  that  cover  higher-order  functions  as 
well.  The  motivation  for  our  choice  of  algebraic  structures  is  discussed  further  in  Sec- 
tion 3.3.  This  section  reviews  the  basic  properties  of  Boolean  algebras  and  shows  how 
to  construct  the  Boolean  algebras  for  higher  order  function  spaces. 

There  are  many  equivalent  definitions  of  Boolean  algebras  [10].  Every  Boolean 
algebra  is  a  complemented  distributive  lattice  with  respect  to  the  partial  ordering 
defined  by  the  relations  x  C  y  <=>  xy  =  x  <=>  x  +  y  =  y.  In  addition  to  the  lattice 
operations  a  Boolean  algebra  has  a  complement  operation,  which  can  be  used  to  define 
a  binary  difference  operator  x  -  y  =  xy  that  obeys  the  algebraic  properties  of  set 
difference.  These  structures  are  important  for  our  goals  of  finding  minimal  compatible 
extensions  and  finding  minimal  change  transformations. 

We  use  notations  for  operations  on  Boolean  algebras  common  in  circuit  design. 
Unfortunately,  these  notations  are  not  the  same  as  those  used  for  lattice  operations  in 
the  context  of  denotational  semantics.   The  correspondence  is  shown  in  Fig.  1  [2]. 

We  will  be  working  with  a  special  class  of  Boolean  algebras,  those  that  are 
atomic.  An  atom,  is  an  element  that  is  distinct  from  the  bottom  element  0  and  has  no 
lower  bounds  other  than  itself  and  o.  A  Boolean  algebra  is  atomic  if  every  element  is 
the  least  upper  bound  of  the  set  of  atoms  it  dominates  (lemma  1,  [10]  p.  70). 

Every  atomic  Boolean  algebra  is  isomorphic  to  the  power  set  of  its  atoms,  which 
becomes  a  Boolean  algebra  when  u ,  ~ ,  and  complement  are  interpreted  as  the  union, 
intersection,  and  complement  operations  on  sets  (theorem  5,  [10]).  This  isomorphism 
demonstrates  that  the  difference  operator  of  a  atomic  Boolean  algebra  really  is  the 
same  as  set  difference.  It  also  implies  that  every  atomic  Boolean  algebra  is  complete 
and  that  its  structure  is  determined  by  its  cardinality.  A  Boolean  algebra  (or  any  lat- 
tice) is  complete  if  and  only  if  it  has  least  upper  bounds  and  greatest  lower  bounds  for 
arbitrary  subsets,  not  just  the  finite  ones. 
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Fig.  1    Correspondence  between  Lattice  Notation  and  Boolean  Notation 
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The  Boolean  algebras  used  in  digital  circuit  design  are  atomic  and  finite:  elements 
can  be  represented  as  fixed-length  vectors  of  bits,  the  atoms  are  all  zero  except  at  one 
bit  position,  and  the  cardinality  of  the  value  set  is  equal  to  a  power  of  two.  The 
Boolean  algebras  we  use  for  semantic  domains  are  mostly  function  spaces,  and  the  car- 
dinality of  the  value  set  is  typically  infinite. 

An  example  of  a  Boolean  algebra  that  is  neither  atomic  nor  complete  is  the  set  of 
all  finite  unions  of  half-open  real  intervals  of  the  form  {jc  I  a  <  x  <  b }  where 
0  <  a  <  b  <  1  and  a  and  b  are  rational  numbers.  The  operations  of  the  algebra  are  ordi- 
nary set-theoretic  unions,  intersections,  and  complements,  the  ordering  is  subset,  the 
bottom  element  is  the  empty  set  (any  interval  with  a  =  b),  and  the  top  element  is  the 
interval  with  a  =  0  and  b  =  1.  To  see  that  this  Boolean  algebra  does  not  have  any 
atoms,  note  that  there  is  an  infinite  descending  chain  below  every  element  other  than 
the  empty  set.  To  see  that  it  is  not  complete,  note  that  any  infinite  set  of  pairwise  dis- 
joint intervals  does  not  have  a  least  upper  bound. 

We  will  find  that  isomorphic  Boolean  algebras  can  be  given  quite  different 
interpretations,  and  that  some  properties  relevant  to  change  merging,  such  as  whether 
or  not  a  given  element  represents  a  semantic  conflict,  can  depend  on  the  intended 
interpretation  as  well  as  on  the  structure  of  the  algebra.  Since  the  intended  interpreta- 
tion of  a  domain  is  determined  by  how  the  domain  was  constructed,  we  implicitly 
label  each  domain  with  the  operation  that  was  used  to  construct  it  and  consider  alge- 
bras constructed  in  different  ways  to  be  distinct.  To  keep  our  conventions  simple  we 
will  follow  this  convention  uniformly  and  explicitly  mention  all  isomorphisms, 
although  this  introduces  some  distinctions  that  are  not  significant.  For  example,  the 
domains  A  x  (B  x  C)  and  (A  x  B)  x  C  are  considered  to  be  different  even  though  they 
are  isomorphic  and  have  essentially  the  same  meaning. 

Our  domain  construction  will  proceed  as  follows.  We  will  take  some  domains  to 
be  given  a  priori,  and  we  will  label  them  as  primitive.  All  other  domains  will  be  con- 
structed from  the  primitive  domains  using  a  fixed  set  of  domain  constructors  and  possi- 
bly reflexive  domain  equations.  The  domain  constructors  are  cross  products,  extended 
disjoint  sums,  and  function  spaces.  Section  3.3  extends  this  by  adding  power  domain 
constructors. 

3.2.1.    Primitive  Domains 

The  domains  representing  ordinary  data  types  will  be  treated  as  primitive.  By  an 
ordinary  data  type  we  mean  a  set  whose  values  are  either  completely  defined  or  com- 
pletely undefined.  Ordinary  data  types  can  include  composite  data  structures  as  long 
as  it  is  not  possible  for  some  subcomponents  to  be  defined  while  others  are  not.  An 
example  of  a  data  type  that  is  not  ordinary  is  a  list  type  with  lazy  evaluation  for  the 
element  extraction  operation,  since  some  components  might  be  well  defined  while  an 
attempt  to  extract  other  components  might  cause  the  program  to  go  into  an  infinite 
loop. 

In  denotational  semantics,  ordinary  data  types  are  represented  as  flat  lattices  or 
flat  epos.  The  Boolean  algebra  representing  an  ordinary  data  type  is  the  power  set  of 
the  type  with  the  usual  set  operations. 


Each  element  of  this  Boolean  algebra  is  a  set  of  values  of  the  data  type  that 
represents  the  least  upper  bound  of  those  values.  Proper  values  of  the  type  are 
represented  as  singleton  sets  of  the  algebra,  and  these  are  the  atoms  of  the  Boolean 
algebra.  The  approximation  relation  C  is  interpreted  as  the  subset  relation,  and  the 
operations  x  +  y,  xy ,  and  x  - y  are  interpreted  as  union,  intersection,  and  set  difference 
operations.  The  completely  undefined  element  o  is  represented  as  the  empty  set,  and 
the  completely  overconstrained  element  1  is  represented  as  the  set  of  all  values  of  the 
data  type. 

For  the  primitive  domains,  semantic  conflicts  are  represented  by  sets  containing 
more  than  one  element.  An  element  x  of  a  primitive  domain  is  conflict-free  if  and 
only  x  C  a  for  some  atom  a .  Note  that  the  undefined  element  0  is  conflict-free  as  well 
as  the  proper  values  of  the  type. 

The  relation  between  the  lattice  construction  and  the  Boolean  algebra  construction 
is  illustrated  in  Fig.  2  [2]  for  a  discrete  type  representing  the  states  of  a  traffic  light. 
Our  construction  preserves  the  structure  of  flat  lattices  everywhere  except  for  the  top 
element  7  ,  which  is  refined  into  a  set  of  distinct  improper  elements  in  the  Boolean 
algebra.  The  Boolean  algebra  can  support  a  total  and  single-valued  difference  operator 
because  the  least  upper  bounds  of  distinct  sets  of  proper  data  elements  are  all  distinct. 
It  is  not  possible  to  define  such  a  difference  operator  for  flat  lattices  with  more  than 
two  elements  because  all  of  these  upper  bounds  are  identified  with  the  single  element 
7   in  the  flat  lattice. 

3.2.2.    Domain  Construction:  Cross  Products 

We  use  the  same  product  space  constructor  used  in  denotational  semantics,  since 
the  product  of  two  atomic  Boolean  algebras  is  an  atomic  Boolean  algebra.  The  atoms 
of  the  product  space  are  the  tuples  that  have  an  atom  as  one  component  and  undefined 
elements  for  all  of  the  other  components. 

An  element  of  a  product  space  contains  a  semantic  conflict  if  one  of  its  com- 
ponents does:  a  tuple  t  e  Dx  x  D2  is  conflict-free  if  and  only  if  t{  and  t2  are  conflict-free. 


r  =  red,   y  =  yellou/,  g  =  green 


Fig.  2   A  Flat  Lattice  and  the  Corresponding  Boolean  Algebra 


Note  that  product  spaces  contain  conflict-free  elements  that  are  not  atoms  and  are  not 
o.  Since  we  can  have  a  product  space  isomorphic  to  a  primitive  domain,  we  can  see 
that  the  "conflict-tree"  property  need  not  be  preserved  by  isomorphism. 

3.2.3.    Domain  Construction:  Extended  Sums 

The  domains  produced  by  the  classical  disjoint  sum  construction  are  not  in  gen- 
eral Boolean  algebras,  nor  can  they  be  embedded  in  Boolean  algebras.  This  is  so 
because  all  Boolean  algebras  are  distributive,  but  disjoint  sums  do  not  in  general  pro- 
duce distributive  lattices.  To  see  this  let  A  and  B  be  atomic  Boolean  algebras  and  con- 
sider any  elements  a.  a'  eA  and  fcefl  that  are  ordered  as  shown  in  Fig.  3.  Such  ele- 
ments exist  whenever  A  contains  at  least  three  distinct  atoms  and  B  contains  at  least 
two  distinct  atoms.   These  elements  fail  to  satisfy  the  distributive  law: 

a  +  (a'  b)  =  a  +  0  =  a  *  a'  =  a'  1  =  (a  +  a'  )(a  +  b ). 

Since  an  embedding  must  preserve  least  upper  bounds  and  greatest  lower  bounds,  these 
elements  will  also  violate  the  distributive  law  in  any  other  lattice  in  which  the  sum 
domain  can  be  embedded. 

We  therefore  reexamine  disjoint  sums  in  the  context  of  change  merging.  To 
accurately  represent  semantic  conflicts,  we  would  like  every  pair  of  proper  data  values 
in  our  semantic  domains  to  have  a  distinct  least  upper  bound.  This  suggests  that  it  is 
not  really  desirable  to  keep  sum  domains  completely  disjoint:  certainly  we  want  the 
parts  of  the  domains  containing  the  proper  elements  to  be  disjoint,  but  we  would  like 
to  have  distinct  representations  for  all  of  the  possible  conflicts  between  the  maximal 
proper  elements  from  the  different  components  of  the  sum.  So  we  suggest  using  cross 
products  under  the  usual  ordering  (Section  3.2.2)  to  encode  extended  disjoint  sums. 

This  is  not  as  unreasonable  as  it  may  at  first  appear:  if  we  restrict  our  attention  to 
the  subset  of  the  pairs  that  have  an  undefined  element  0  in  at  least  one  component,  the 
ordering  on  the  cross  product  space  is  exactly  the  same  as  the  ordering  on  a  coalesced 


Fig.  3   Disjoint  Sums  Are  Not  Distributive 


sum  domain.  The  elements  outside  this  subset  all  represent  conflicts  between  elements 
from  different  components  of  the  disjoint  sum,  and  can  be  treated  as  not  belonging  to 
either  component  of  the  "sum".  If  we  "encode"  disjoint  sums  as  product  domains,  the 
injection  functions  in,,  the  discrimination  functions  is,,  and  the  projection  functions 
out;  that  are  usually  used  in  the  definitions  of  semantic  functions  involving  sum 
domains  can  be  defined  as  follows. 

int0c)  =  (x.  0)  in20c)  =  (0.  x) 

is,(/7)  =  (p:  *  0)  &  (p2  =  0)  is,(p)  =  (px  =  0)  <£  (p2  *  0) 

out;  ip )  =  if  is,  (p )  then  p,  else  if  p  =  (0,  0)  then  0  else  1 

Thus  the  encoding  appears  to  be  a  workable  (though  not  very  elegant)  solution  that 
allows  domain  constructions  involving  sum  constructors  to  be  simulated  by  using  cross 
products,  which  do  yield  Boolean  algebras. 

An  element  of  an  extended  sum  domain  contains  a  conflict  if  either  component 
has  a  conflict  or  if  we  do  not  have  a  o  in  at  least  one  component:  an  element 
x  e  D{  +  D2  is  conflict-free  if  and  only  if  x{  and  x2  are  conflict-free  and  either  x{  =  <>  or 
x2  =  0. 

3.2.4.    Domain  Construction:  Function  Spaces 

The  continuous  function  space  constructor  of  denotational  semantics  does  not 
preserve  Boolean  algebras,  but  the  function  space  construction  used  in  ordinary 
mathematics  does.  If  A  and  B  are  atomic  Boolean  algebras,  then  the  complete  func- 
tion space  A  -¥  B  is  the  atomic  Boolean  algebra  whose  elements  are  all  of  the  func- 
tions from  A  to  B  with  the  natural  pointwise  ordering.  The  ordering,  distinguished  ele- 
ments, and  operations  of  the  function  space  are  described  by  the  following  relation- 
ships. 

(a)  fg  g  <=>  VxeA[/Cc)L  g(x)) 

(b)  ou)  =  o 

(c)  i(x)  =  1 

(d)  (/  -  gXx)=  f(x)+  g(x) 

(e)  (/  g)(x)=  f(x)g(x) 

(f)  (/  )U)  =  f(x) 

(g)(/  -  SX*)-  /CO-  g(x) 
The  relation  (a)  is  the  standard  ordering  for  function  spaces  in  denotational  semantics, 
and  implies  relations  (b)  -  (g).  The  relations  (b)  and  (c)  describe  the  connection 
between  the  top  and  bottom  elements  of  the  function  space  A  -» B  and  the  top  and  bot- 
tom elements  of  its  range  algebra  B.  The  relations  (d)  -  (g)  are  homomorphic  exten- 
sion rules  which  define  the  operations  of  the  function  space  in  terms  of  the  operations 
of  its  range  algebra.  The  operations  are  well  defined  because  5  is  complete,  so  that 
least  upper  bounds  exist  for  all  subsets  of  its  atoms.  The  Boolean  algebra  properties 
are  satisfied  for  the  function  space  because  they  are  satisfied  by  the  values  of  the  func- 
tions at  each  point  in  A . 

The  resulting  function  space  is  an  atomic  Boolean  algebra.  The  atoms  of  A  -*  B 
are  functions  g[x,  y]  that  are  undefined  at  all  points  of  the  input  space  A  except  for  the 
point  x,  and  have  the  value  y  at  that  point,  where  x  can  be  any  point  in  A  and  y  can 


be  any  atom  of  B : 

g[x,  y](z)  =  if  x  =  :  then  y  else  0. 

Every  element  of  the  function  space  is  the  least  upper  bound  of  the  atoms  it  dominates 
because  the  corresponding  property  is  true  in  B  for  the  values  of  those  functions  at 
every  point  in  A ,  since  B  is  an  atomic  Boolean  algebra. 

The  classical  function  space  construction  used  in  denotational  semantics  produces 
subsets  of  our  function  spaces.  Note  that  we  cannot  limit  the  construction  to  just  the 
monotonic  functions  (or  just  the  continuous  functions),  because  a  Boolean  algebra 
must  be  closed  under  complements,  and  the  complement  of  a  monotonic  function  is 
anti-monotonic. 

Since  our  function  spaces  are  complete,  they  satisfy  the  weaker  completeness  pro- 
perties needed  to  show  the  existence  of  least  fixed  points  of  continuous  functions. 
They  also  contain  all  of  the  continuous  functions,  and  hence  support  recursive 
definitions  for  elements  of  the  function  spaces. 

A  function  contains  a  conflict  if  its  value  at  some  meaningful  point  contains  a 
conflict:  a  function  /:  D,  ->  Dz  is  conflict-free  if  and  only  if  fix)  is  conflict-free  for  all 
conflict-free  xeD\.  We  restrict  our  attention  to  the  conflict-free  points  in  £>.  because 
computable  (monotonic)  functions  can  be  expected  to  produce  conflicts  at  overdefined 
points. 

3.2.5.    Domain  Construction:  Reflexive  Domains 

Reflexive  domains  are  the  solutions  to  recursive  domain  equations,  in  which 
equality  is  interpreted  as  lattice  isomorphism.  Since  our  function  spaces  contain  all 
functions,  our  function  space  constructor  strictly  increases  the  cardinality  of  the  space, 
so  we  cannot  hope  to  find  spaces  that  are  isomorphic  to  their  own  function  spaces. 
This  is  one  of  the  classical  problems  in  denotational  semantics,  and  it  implies  that  the 
function  space  construction  of  Section  3.2.4  cannot  be  used  in  recursive  domain  equa- 
tions. However,  if  we  are  willing  to  restrict  ourselves  to  distributive  lattices  and 
embed  solutions  to  domain  equations  in  larger  Boolean  algebras,  there  is  a  way  out  via 
the  space  of  continuous  functions  used  in  denotational  semantics. 

We  start  with  a  lemma  that  relates  properties  of  domain  constructors  to  the  pro- 
perties of  reflexive  domains  defined  using  those  constructors. 

Lemma  1.  If  F  is  a  continuous  domain  constructor  [23]  that  preserves  distributiveness 
then  the  minimal  solution  to  the  domain  equation  D  =  F(D )  exists  and  is  distributive. 
Indeed,  any  property  that  is  preserved  by  the  domain  constructors  and  can  be 
expressed  as  an  equation  or  inclusion  between  expressions  denoting  elements  of  a 
domain  is  satisfied  in  D. 

Proof:  D  exists  by  (theorem  4.2.8,  [23]).  The  minimal  domain  i  contains  only  one 
point,  so  all  inclusions  and  equations  on  elements  are  trivially  satisfied,  and  in  particu- 
lar we  have  x  u  (y  n : )  =  (x  l y ) n  (x  u z )  and  x  n  (y  Li  z)  =  (x  n  y )  u  (x  n z)  for  all 
x,  y,  ze  i.  So  the  domain  i  is  distributive.  Since  F  preserves  distributiveness,  the 
approximating  domains  F"(_  )  are  distributive  for  all  natural  numbers  n,  by  induction. 
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By  (lemma  4.2.5,  [23]),  x  Z.  y  <*>\fcfor*(x)C  *„'(>)],  where  jt„*  are  the  projection  func- 
tions from  D  into  F"(_l  )  defined  in  [23].  (Two  elements  of  the  limiting  domain  are 
ordered  if  and  only  if  their  projections  into  all  of  the  approximation  domains  are 
ordered  in  the  same  way).  This  implies  xlly  -z  in  D  <=>  Vn[ic*(x)Uizj(y)  ■  itjiz)] 
and  similarly  for  r, .  Since  x  =  y  <=>  x  Z  y  &  y  Z  x  we  also  have  x  =  y  in  D  <=> 
\/n[n*(x)  =  n*(y)].  By  structural  induction  it  follows  that  any  equation  among  finite 
expressions  built  using  variables,  U ,  and  n  is  satisfied  in  the  limit  domain  D  if  and 
only  if  the  expression  with  each  variable  v  replaced  by  the  corresponding  projection 
rt„*(v)  it  is  satisfied  in  all  the  approximating  domains  F"(  i  ).  So  D  must  be  distributive, 
since  all  of  the  approximating  domains  are  distributive. 

Now  we  can  proceed  to  the  main  theorem. 

Theorem  1.  The  solution  to  any  domain  equation  composed  of  given  Boolean  alge- 
bras and  domain  constructors  that  preserve  distributiveness  can  be  embedded  in  a 
Boolean  algebra. 

Proof:  Boolean  algebras  are  distributive  lattices  by  definition.  Lemma  1  says  that  the 
solution  to  a  domain  equation  composed  of  domain  constructors  that  preserve  distribu- 
tiveness is  also  a  distributive  lattice.  Every  distributive  lattice  can  be  extended  to  a 
Boolean  algebra  ([16],  p.  450  ff.).    So  the  result  follows. 

The  primitive  domains  of  Section  3.2.1  are  all  Boolean  algebras.  Cross  products 
and  function  spaces  of  distributive  lattices  are  distributive  (theorem  13,  [17],  Ch.  14). 
The  lattice  of  continuous  functions  is  distributive  because  it  is  a  sublattice  of  the  full 
function  space.  Extended  disjoint  sums  are  encoded  as  cross  products  in  Section  3.2.3. 
So  the  solution  to  any  domain  equation  expressed  using  these  constructs  will  be  a  dis- 
tributive lattice,  which  can  be  embedded  in  a  Boolean  algebra.  This  Boolean  algebra 
is  a  good  candidate  for  hosting  change  merging  operations  because  it  is  a  natural  com- 
pletion of  the  semantic  domain  that  contains  distinct  representations  for  all  possible 
conflict  elements. 

The  solution  to  a  reflexive  domain  equation  is  labeled  with  the  outermost  domain 
constructor  on  its  right  hand  side,  and  the  appropnate  definition  of  conflict-free  ele- 
ments is  determined  accordingly. 

These  constructions  allow  us  to  formulate  change  merging  operations  for  most  of 
the  programming  languages  covered  by  classical  denotational  semantics.  This  does  not 
include  the  class  of  languages  with  parallel  or  nondeterministic  operations,  which  are 
considered  briefly  in  the  next  section. 

3.3.   Browerian  Algebras 

Boolean  algebras  are  sufficient  for  modeling  the  semantics  of  change  merging  for 
the  programming  languages  whose  semantics  can  be  expressed  using  the  constructions 
of  Section  3.2.  Some  work  on  concrete  methods  for  change  merging  has  been  based 
on  a  more  general  class  of  Browerian  algebras  [21].  This  section  discusses  the  role  of 
Browerian  algebras  in  modeling  the  semantics  of  change  merging. 
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A  Browerian  algebra  is  a  lattice  with  a  pseudo-difference  operation  -  that 
satisfies  the  property  x  -  y  Z  z  <=>  x  ~  y  +  :.  Every  Boolean  algebra  becomes  a 
Browerian  algebra  when  it  is  equipped  with  a  difference  operator  as  defined  in  Section 
3.2,  but  there  exist  Browerian  algebras  that  are  not  Boolean  algebras.  In  particular, 
Browerian  algebras  need  not  satisfy  the  law  T  =  x.  The  difference  operator  of  a 
Boolean  algebra  must  satisfy  both  of  the  following  properties. 

PL  (x  -  y)  +  (xy)  =  x 
P2.  (x  -y)y  =0 

The  pseudo-difference  operator  of  a  Browerian  algebras  must  satisfy  PI,  which  says 
that  all  of  the  information  in  x  is  either  contained  in  y  or  is  contained  in  the  part  of  x 
that  is  not  in  y :  (x  -y)  +  (xy)  =  (U  -  y)  +  x)((x  -  y)  +  y)  =  x(x  +  y )  =  x  if  we  note  that 
x  -  y  Z  x  and  use  (proposition  A.12,  [21]).  However,  the  pseudo-difference  operator 
may  fail  to  satisfy  P2,  which  says  that  the  result  of  removing  y  from  x  does  not  con- 
tain any  of  the  information  in  y .  It  is  easy  to  see  that  this  disjointness  property  holds 
in  a  Boolean  algebra:  (x  -  y)y  =xvy  =.cO  =  o.  The  pseudo-difference  operator  is  thus 
not  really  a  difference  operator,  because  it  may  not  remove  all  of  the  information  con- 
tained in  y,  although  it  must  remove  as  much  as  possible  without  violating  property 
PI.  This  means  that  the  underlying  lattice  of  a  Browerian  algebra  need  not  have 
sufficiently  fine  resolution  to  separate  x  and  y .  in  the  sense  that  it  may  not  be  possible 
to  remove  all  of  the  information  in  y  from  x  without  also  removing  some  information 
in  x  that  is  not  contained  in  y . 

We  have  worked  with  Boolean  algebras  because  they  provide  a  natural  represen- 
tation for  precisely  identifying  the  sources  of  semantic  conflicts,  proofs  are  simpler, 
and  the  extra  generality  of  Browerian  algebras  is  not  needed  to  express  the  semantics 
of  change  merging  for  most  programming  languages.  Separating  the  elements  of  the 
semantic  domains  in  the  sense  of  the  previous  paragraph  is  usually  not  an  issue 
because  the  data  values  of  most  programming  languages  are  disjoint  (can  be  modeled 
as  a  flat  cpo)  or  can  be  assembled  from  disjoint  parts  (using  cross  products  or  func- 
tions). 

Browerian  algebras  were  used  in  [21]  because  the  concrete  dependence  graph 
representations  of  programs  do  not  have  a  Boolean  algebra  structure.  However,  we 
note  that  the  semantic  correctness  of  the  HPR  algorithm  [12]  as  well  as  of  the  variant 
in  [21]  is  not  derived  from  the  Browerian  algebra  structure  of  the  dependence  graph 
representations  of  the  programs,  but  rather  from  the  concrete  properties  of  program 
slices. 

A  realistic  example  of  a  semantic  domain  that  should  properly  be  modeled  as  a 
Browerian  algebra  is  the  domain  of  maximum  execution  times  (METs)  for  a  language 
with  hard  real-time  constraints  such  as  PSDL  [8].  Since  a  larger  number  represents  a 
weaker  timing  constraint,  the  approximation  ordering  l  for  this  domain  is  the  total 
ordering  >  on  numerical  values.  This  is  an  extreme  example  of  lack  of  separability 
because  two  constraints  cannot  be  disjoint  unless  one  of  them  is  the  vacuous  constraint 
oo  (the  bottom  element  of  the  lattice).  The  lattice  of  MET  values  is  a  Browerian  alge- 
bra with  x  -y  =tfxQy  then  °»  else  x .  Since  every  Browerian  algebra  is  a  distributive 
lattice  (theorem  1.3,  [19]),  every  Browerian  algebra,  including  the  MET  domain,  can 
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be  extended  to  a  Boolean  algebra  by  ([16],  p.  450  IT.).  A  fragment  of  the  MET 
domain  and  its  embedding  in  a  Boolean  algebra  are  shown  in  Fig.  4,  where  proper  ele- 
ments have  bold  lines  and  the  artificial  elements  added  by  the  embedding  have  thin 
lines.  Unlike  the  extended  data  domains  of  Section  3.2,  where  the  artificial  elements 
represent  conflicts  between  distinct  proper  elements,  the  extra  elements  in  this  exten- 
sion to  a  Boolean  algebra  provide  artificial  differences  between  proper  elements  that  do 
not  have  realistic  interpretations.  Change  merging  in  this  Boolean  algebra  can  result  in 
an  improper  element,  while  change  merging  in  the  Browerian  algebra  yields  a  proper 
element  that  dominates  the  result  in  the  Boolean  algebra.  For  example,  merging  the 
change  from  2  to  1  with  the  change  from  2  to  3  according  to  the  model  explained  in 
Section  4  yields  the  improper  element  (1  -  2)  +  (1)(3)  +  (3-2)  ■  3  +  (1  -2)  in  the 
extended  Boolean  algebra  and  the  dominating  proper  element  (1  -  2)  +  (1)(3)  +  (3  -  2)  =  1 
in  the  Browerian  algebra,  where  +  and  -  denote  the  operations  from  these  algebras 
instead  of  the  usual  operations  from  arithmetic.  This  suggests  Browerian  algebras  may 
provide  appropriate  change  merging  models  for  data  domains  with  overlapping  proper 
elements  that  cannot  be  separated  into  disjoint  proper  components. 

A  standard  construction  for  Browerian  algebras  involves  topological  closure 
operations  [18].  A  topological  closure  operation  on  a  Boolean  algebra  of  sets  is  a 
function  from  sets  to  sets  that  satisfies  the  following  properties  for  all  sets  x  and  y  in 
the  domain  of  the  Boolean  algebra: 

(CI)  x  c  C(x), 

(C2)  C(C(x))  =  C(x), 

(C3)  CUuy)  =  CU)uC(y)  and 

(C4)C({})={) 

Note  that  many  "closure"  operations  commonly  used  in  computer  science  are  not  topo- 
logical closure  operations.  For  example,  the  transitive  closure  of  a  graph  does  not 
satisfy  condition  C3.    A  set  x  is  closed  relative  to  C  if  Cix)  =  x.   The  closed  elements 


Fig,  4   Extending  the  MET  Browerian  Algebra  to  a  Boolean  Algebra 
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of  any  Boolean  algebra  of  sets  with  a  topological  closure  operation  C  forms  a 
Browerian  algebra  under  the  operation  x  -y  =  C(x  -  y)  (theorem  1.14,  [19])  and  every 
Browerian  algebra  is  isomorphic  to  an  algebra  constructed  in  this  way  (theorem  1.15, 
[19]).  The  connection  to  topology  is  that  every  topological  space  is  a  Browerian  alge- 
bra and  every  Browerian  algebra  is  isomorphic  to  a  subalgebra  of  the  algebra  of  closed 
sets  of  a  topological  space  (theorem  1.19,  [19]). 

In  particular,  the  set  of  all  downwards  closed  subsets  of  any  lattice  forms  a 
Browerian  algebra  under  the  construction  outlined  above.  The  downwards  closure  is 
defined  by  DC (s)  =  {y  I  3x  e  s.y  Z  x },  and  can  easily  be  seen  to  satisfy  the  properties  of 
a  topological  closure  operation.  Similar  results  hold  for  the  upwards  closure 
UC(s)  =  { y  I  3x  e  s.x  ~  y}.   These  properties  turn  out  to  be  relevant  to  power  domains. 

3.3.1.    Domain  Construction:  Power  Domains 

We  saw  in  Section  3.2  how  the  semantic  domains  for  many  classical  program- 
ming languages  can  be  naturally  embedded  in  Boolean  algebras.  The  constructions  of 
Section  3.2  do  not  cover  languages  with  parallelism  and  nondeterministic  constructs, 
whose  semantic  domains  usually  include  power  sets  (power  domains).  Several 
varieties  of  power  domain  constructions  have  been  proposed  for  defining  the  semantics 
of  programming  languages  with  parallelism.  The  approximation  orderings  on  these 
domains  are  only  quasi-orderings,  and  the  relation  x  =  y  <=>  x  Z.  y  &  y  Z.  x  is  an 
equivalence  relation  that  is  weaker  than  equality.  The  approximation  relation  becomes 
a  partial  ordering  on  equivalence  classes  in  the  quotient  lattices  with  respect  to  this 
equivalence  relation,  but  it  is  less  cumbersome  to  represent  each  equivalence  class  by 
its  largest  member  (the  set  with  the  most  elements).  There  are  three  main  variations 
on  the  power  domain  construction:  the  Hoare  power  domain,  the  Smyth  power  domain, 
and  the  Egli-Milner  power  domain.  It  turns  out  that  the  equivalence  classes  for  the 
Hoare  power  domain  are  represented  by  the  downwards  closed  subsets  of  the  underly- 
ing lattice,  those  for  the  Smyth  power  domain  are  represented  by  the  upwards  closed 
subsets,  and  those  for  the  Egli-Milner  power  domain  are  represented  by  the  convex 
closed  subsets  [23]. 

Since  the  downwards  closure  and  the  upwards  closure  satisfy  the  topological  clo- 
sure properties  C1-C4  above,  the  Hoare  and  Smyth  power  domains  have  a  natural 
Browerian  algebra  structure,  which  implies  that  they  are  distributive  lattices  and  can  be 
extended  to  Boolean  algebras.  This  implies  that  our  model  of  the  semantics  of  change 
merging  can  be  applied  to  both  the  Hoare  and  Smyth  power  domains,  and  that  theorem 
1  can  be  applied  to  reflexive  domain  equations  containing  these  power  domain  con- 
structors. We  leave  open  the  question  of  whether  the  Browerian  or  the  Boolean  model 
of  change  merging  is  more  appropriate  for  these  domains. 

An  element  of  a  power  domain  represents  a  set  of  possible  outcomes.  Such  an 
element  has  a  semantic  conflict  if  any  of  the  possible  outcomes  have  a  conflict:  a  set 
s  e  P{D)  is  conflict-free  if  and  only  if  x  is  conflict-free  for  all  x  e  s. 

We  note  that  the  convex  closure  CC(s)  =  {y  I  3x,  z  <=  s.x  Z  y  l  z  }  does  not  satisfy 
the  topological  closure  property  C3  above,  so  it  is  not  a  topological  closure  operation 
and  does  not  support  the  Browerian  algebra  construction.    In  fact,  the  Egli-Milner 
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power  domain  is  not  in  general  a  distributive  lattice,  as  demonstrated  by  the  following 
counterexample.  Fig.  5.  shows  a  four  element  Boolean  algebra  (a)  and  the  Egli-Milner 
power  domain  derived  from  it  (b).  This  power  domain  is  not  a  distributive  lattice 
because  {a,  b)  u  ({a.b,  1}  n  [a])  =  [a,  b]  U  {0.  a}  =  {a.b}  *  [a.b.  1}  = 
{a,  b,  1}  n  {a.  1}  =  {{a,b}  u  [a,  b,  1})  "  ({a.b}  u  ({a  })  where  the  least  upper 
bounds  and  greatest  lower  bounds  are  taken  with  respect  to  the  Egli-Milner  ordering 
[23]  shown  in  Fig.  5.  (b).  Since  every  Browerian  algebra  is  a  distributive  lattice, 
Egli-Milner  power  domains  cannot  be  extended  to  Browerian  (or  Boolean)  algebras. 

We  conclude  that  none  of  the  known  models  of  change  merging  apply  to 
languages  whose  semantics  involve  Egli-Milner  power  domains,  since  all  of  these 
models  depend  on  (at  least)  a  Browerian  algebra  structure.  This  issue  is  relevant  to 
applications  where  programs  that  can  fail  to  terminate  must  interact  in  a  nondeter- 
ministic  way  (typically  via  parallel  processing).  The  formulation  of  an  appropriate 
model  of  change  merging  for  this  class  of  languages  is  left  as  an  open  problem. 

4.    Language-Independent  Model  of  Software  Merging 

This  section  discusses  some  properties  of  the  change  merging  operator  in  [2], 
which  is  defined  as  follows. 


9 

(a)  Boolean  Algebra  (b)  Deriued  Pouuer  Domain 

Fig.  5   The  Egli-Milner  Power  Domain  is  not  Distributive 
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/[*]/»  =  (/-  g)+  f  h  +  (h-  g) 


(Ml) 


We  know  that  (/-  g)  +  /  h  +  (  A  -  g)  »  (/  -  g)+fgh  +  (h-  g)  because 
fh=fh(g  +  ~g)=fgh+f~g  h  and  /"J  A I  "5  h  =  (  h-  g)  (this  equivalence  holds 
also  for  Browerian  algebras,  but  the  proof  is  longer).  Thus  our  definition  of  f[g]h 
coincides  with  the  negmajority  operation  f[g]h  defined  in  [11]  and  the  integration 
operation  fig]  li  defined  in  [21].  The  name  "negmajority"  was  motivated  by  a  prepo- 
sitional calculus  interpretation  of  a  Boolean  operator  that  is  true  if  and  only  if  a  major- 
ity of  the  three  values  is  true  after  the  middle  value  is  negated.  Our  operator  defines 
the  same  Boolean  function,  but  it  is  interpreted  in  a  much  larger  Boolean  algebra 
representing  the  space  of  meaning  functions  for  programs,  rather  than  in  the  two- 
valued  Boolean  algebra  of  prepositional  calculus.  Reps'  version  of  /  [  g]  h  is  defined 
in  terms  of  the  pseudo-difference  operation  of  a  Browerian  algebra,  instead  of  the 
difference  operation  of  a  Boolean  algebra,  because  the  graphs  used  to  represent  pro- 
grams in  his  algorithm  do  not  satisfy  all  the  properties  of  a  Boolean  algebra.  How- 
ever, we  have  seen  in  Section  3  that  the  semantic  domains  for  sequential  programs  can 
be  extended  to  Boolean  algebras. 

4.1.   The  Relation  to  Minimal  Change  Transformations 

Informally,  an  operation  for  combining  changes  to  functions  should  be  able  to 
apply  the  change  defined  by  the  difference  between  two  versions  g  and  /  of  a  func- 
tion to  some  other  version  h.  In  [2]  we  showed  how  to  infer  a  mapping  from  versions 
to  versions  from  the  effect  of  a  change  on  a  particular  base  version  g.  This  was  done 
by  characterizing  the  change  from  a  function  g  to  a  function  /  in  terms  of  the  com- 
mon part  /  g,  the  part  that  was  added  /  -  g,  and  the  part  that  was  removed  g  -  / ,  as 
illustrated  in  Fig.  6.  [2].  These  components  were  shown  to  be  disjoint  and  to  contain 
all  of  the  information  in  the  functions  /  and  g,  so  that  any  change  to  a  function  can 
be  characterized  by  the  part  that  was  added  and  the  part  that  was  removed. 

We  formalize  the  idea  of  a  transformation  /  [  g]  that  changes  a  base  version  g 
into  a  modified  version  /  as  follows.  We  propose  that  change  transformations  should 
be  functions  of  the  form  T[a,  b]  where  T[a,  b](x)  =  U  -a)  +  b  for  all  x,  and  seek  the 
smallest  transformation  such  that  T[a,b](g)  =  f   (relative  to  the  ordering  defined  by 


Fig.  6   Characterizing  Software  Changes 
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T[au  b\]Z  T[a2,  b2]    <=>    ax  Z  a2  &  bx  Z  b2).    This  is  based  on  the  following  assump- 
tions: 

(1)  The  information  added  as  well  as  the  information  removed  by  a  given  change 
transformation  should  not  depend  on  what  version  the  change  transformation  is 
applied  to,  and 

(2)  The  only  additions  and  removals  included  in  the  change  transformation  should  be 
those  necessary  to  transform  g  into  /. 

As  was  suggested  in  [2],  these  assumptions  uniquely  determine  f[g]: 
f[g]=T[g-f-f-g]-  To  see  that  this  change  transformation  maps  g  into  /  note 
that  T[g-  f.f-  g](g)=  (g  -ig-  f ))  +  (/-  g)  =  g~7f  +  fl=  gl+g7  +  lf  = 
9  +  (g  +  ~g)f  a  /.  To  see  that  it  is  the  smallest  such  transformation,  suppose  that 
( g  -  a )  +  b  =  / .  Then  /  -  g  =  f~g  =  (  ga  +  b)~g  =  g~ga  +  b~g  =  b~gZ  b  and 
g-  f  =     gj=     g(  gii  +b)=    g(~g  +  a )b  =   ab  ~  a.    So  T[  g  -  f.  f  -  g]  Z  T[a.  b]. 

This  minimality  property  suggests  that  change  merging  should  be  defined  by 
/[  g]  h  =  (  h  -  (  g  -  /))  +  (/  -  g).   This  was  shown  to  be  equivalent  to  (Ml)  in  [2]. 

We  now  assess  the  adequacy  of  our  formalization  of  the  change  merging  process. 
By  identifying  programs  with  the  functions  they  compute,  we  have  ignored  non- 
functional attributes  such  as  computational  efficiency  and  program  understandability. 
The  result  of  a  change  merging  operation  must  certainly  compute  the  correct  function, 
and  it  may  be  subject  to  other  constraints.  These  other  constraints  are  beyond  the 
scope  of  the  current  paper.  Change  merging  that  involves  efficiency-improving 
modifications  is  addressed  in  [2],  which  suggests  a  method  for  program  change  merg- 
ing that  can  accommodate  efficiency  improving  changes  as  well  as  changes  in  program 
behavior.  This  method  prefers  program  realizations  from  the  changed  versions  over 
those  in  the  base  program  in  cases  where  several  different  realizations  of  the  same 
semantic  (sub-)function  are  present.  The  difficulty  of  recognizing  efficiency-improving 
changes  increases  sharply  with  the  size  of  the  change  and  is  undecidable  in  general. 
Automated  capabilities  in  this  area  are  necessarily  limited,  and  can  be  augmented  with 
declarations  of  programmer  intent  in  the  form  of  optional  specifications  for  program 
fragments. 

A  related  concern  is  the  treatment  of  programs  that  do  not  terminate.  Our  formal- 
ization of  change  merging  is  intended  to  apply  to  any  programming  language  that  can 
be  modeled  by  meaning  functions  over  a  fairly  wide  class  of  semantic  domains,  as 
described  in  Section  3.2.  The  effect  of  the  change  merging  function  defined  in  this 
section  depends  on  the  semantic  model  of  the  programming  language  being  discussed. 
These  models  can  differ  considerably.  In  a  simple  imperative  language  whose  pro- 
grams denote  functions  from  states  to  states,  a  program  that  immediately  enters  an 
infinite  loop  is  equivalent  to  one  that  causes  some  state  changes  and  then  enters  an 
infinite  loop,  because  in  both  cases  there  is  no  final  state,  and  hence  there  are  no 
observable  results.  Thus  a  change  from  the  first  program  to  the  second  would  have  no 
effect  on  program  behavior,  since  we  would  have  «-/=o=/-  g.  For  languages 
with  I/O  facilities,  programs  can  denote  functions  from  pairs  (containing  an  input 
sequence  and  a  state)  to  pairs  (containing  an  output  sequence  and  a  state).  In  such  a 
model,   a   program    that   enters   an   infinite   loop   immediately   computes   a   different 
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function  than  a  program  that  first  produces  some  output  and  then  enters  an  infinite 
loop.  A  change  from  one  to  the  other  would  have  definite  effect  on  program  behavior 
in  such  a  case.  A  different  approach  to  specifying  the  semantics  of  programs  that  are 
not  intended  to  terminate  can  be  found  in  [3]. 

4.2.  Change  Merging  does  not  Preserve  Monotonicity 

In  Section  3  we  motivated  the  need  for  function  spaces  containing  functions  that 
are  not  monotonic  via  a  rather  indirect  argument  Now  we  are  in  a  position  to  show 
that  change  merging  can  produce  non-monotonic  functions  from  monotonic  ones.  The 
following  example  shows  three  simple  monotonic  functions  that  produce  a  non- 
monotonic function  via  change  merging. 

x  fix)      g(x)       h(x)      (f[g]h)(x) 

2  2  2  i  i 

i         2  i  _         2 

Since  every  computable  function  is  monotonic,  this  shows  that  the  result  of  merging 
changes  from  computable  functions  to  computable  functions  need  not  be  computable. 
Thus  the  presence  of  conflicts  is  not  the  only  factor  that  can  lead  to  a  situation  where 
there  does  not  exist  any  program  that  realizes  the  merge  defined  by  a  base  program 
and  two  modified  programs.  This  also  shows  that  the  domains  of  traditional  denota- 
tional  semantics  must  be  extended  to  treat  change  merging  as  a  total  operation. 

4.3.  Commutativity  and  Order  Dependence 

Some  of  the  known  properties  [11,21]  of  the  change  merging  operation  are 
shown  below. 

1.  h[a]c  =  c[a]b 

2.  (b[a]c)[a]d  =  b[a](c[a]d) 

If  we  treat  [a]  as  a  binary  operation,  the  first  property  says  [a]  is  commutative, 
and  the  second  says  that  [a]  is  associative.  These  properties  imply  that  the  order  in 
which  a  set  of  changes  to  the  same  base  version  is  combined  does  not  matter. 

We  can  also  see  that  in  general  two  change  transformations  commute  whenever 
neither  one  removes  information  that  the  other  adds.  We  can  view  the  change  merging 
operation  as  the  application  of  a  function  T[a.  b]  to  a  program.  Since 
( /  -  g)(  g  -  f)  -  °  we  know  that  every  change  merging  operation  corresponds  to  a 
change  transformation  T[a.  b]  for  which  ab  =  <>.  This  says  that  in  a  minimal  change 
transformation,  none  of  the  information  that  is  removed  is  added  back.    We  have 

Ticin,  b2](T[ax,  bi\(x))  =  (((x  -  ai)  +  /;,)  -  03)  +  bi  =  x  <i\   a2  +  bx  a2  +  b2, 
T[ax,  biKTlay  b2](x))  =  (((*  -  a2)  +  bj)  -  a^)  +  bx  =  x  a2  ii\   +b2Ui   +b{. 

Clearly    these    are    the    same    if  b{cil  =bx    and   b2a~x   =  b2.     These   conditions  are 

equivalent  to  bx  C  JT  ^d  &:  Q  ^i"<  which  are  equivalent  to  bxa2  =  0  and  b2a\  =  ().  So 

these  conditions  are  sufficient  for  the  transformations  to  commute.  To  see  they  are 
necessary,  assume  the  transformations  commute,  and  substitute  a  x  for  x : 
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ax  ax   a2  +  bx  a2  +  b2=axa2  (i\   +  b2  a[   +  blt 
ti  +  bxa2  +  b2  =  Q  +  b2ax   +  bx, 
b\  a2  +  b2  =  b2  ax   +  bx. 

If  we  multiply  both  sides  by  a ,  we  get 

axbxa2  +  axb2  =  b2ax  ax  +  axbx, 
0  +  axb2  -  0  +  0, 
axb2  =  0. 

Similarly,  a2bx  =  0.    Thus  we  have  shown  that  f[g](t[u]x)  =  t[u](f[g]x)  if  and  only  if 
(/  -  g)(u  -  0  =  0  and  (t  -  u)<  5  -  /)  =  0. 

This  result  tells  us  what  we  must  check  to  see  whether  a  set  of  changes  will  give 
us  the  same  result  independently  of  the  order  in  which  the  changes  are  merged.  In 
case  some  changes  override  each  other,  in  the  sense  that  one  removes  information  that 
another  adds,  then  applying  the  same  changes  in  a  different  order  can  intuitively  be 
expected  to  give  different  results:  the  last  transformation  to  be  applied  gets  the  final 
say  about  what  should  be  done  about  the  disputed  information  (to  add  or  to  remove). 
In  such  cases,  human  guidance  is  needed  to  resolve  the  relative  priority  between  the 
two  changes,  possibly  by  going  back  to  the  requirements  and  the  underlying 
justifications,  and  determining  which  change  is  more  important. 

4.4.    Properties  Related  to  Functional  Composition 

Independent  modules  are  a  basic  requirement  for  programming  on  a  large  scale. 
We  would  like  to  have  localized  methods  for  analyzing  and  processing  programs,  so 
that  the  analysis  can  be  decomposed  into  smaller  independent  subproblems.  Such 
decoupling  makes  human  understanding  of  large  systems  possible,  as  well  as  con- 
current team  efforts.  It  also  leads  to  computational  efficiency  and  opportunities  for 
parallel  computation  in  automated  processing  of  programs.  Thus  to  shed  some  light  on 
the  feasibility  of  change  merging  for  large  systems,  we  consider  the  interaction 
between  program  merging  and  functional  composition,  which  we  denote  by  /  0  g 
where  (/  „  g)(x)  =  /(  g(x)).  The  urge  to  divide  and  conquer  leads  us  to  investigate  the 
following  distributive  property. 

(?)     if 20  f OH820  gOKko  Ii0  =  (/zig2]b2)o(fdgi]bx) 

This  expression  describes  two  changes  to  an  implementation  that  consists  of  two 
modules,  where  the  output  of  the  front  end  module  gx  is  connected  with  the  input  of 
the  back  end  module  gz.  The  left  hand  side  represents  the  result  of  merging  two 
changes  to  the  system  in  one  big  operation,  while  the  right  hand  side  merges  the 
changes  to  the  front  end  and  the  changes  to  the  back  end  in  two  independent  opera- 
tions and  then  connects  the  merged  versions  together.  Although  this  distributive  pro- 
perty appears  to  be  plausible,  it  turns  out  to  be  false,  as  illustrated  by  the  following 
example  over  the  data  values  {1,  2,  3,  4}. 
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Example  1. 

x       /:     <?:      h     f2[g2]h2      /,     5i      h\     f\[g\]h\      /:(  gi)  h2  »  f  d  gi)  h\ 
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4      3  2  4  3U4 

This  example  shows  that  the  desired  distributive  property  can  be  false  even  for  well 
behaved  functions  and  changes  that  do  not  conflict  (compare  the  results  for  x  =  2  or 
x  =  3).  This  negative  result  is  somewhat  surprising,  because  it  implies  that  changes  to 
sub-functions  can  interfere  even  for  purely  functional  programs.  The  interference 
effect  demonstrated  above  is  thus  completely  unrelated  to  classical  concerns  about  cou- 
pling between  modules  due  to  side  effects  or  state  changes. 

Although  the  interference  effect  comes  from  different  coincidences  of  equal 
values  in  different  versions  of  the  functions,  it  is  not  caused  by  several  different  values 
being  mapped  to  the  same  value  by  the  individual  functions:  note  that  all  of  individual 
functions  in  Example  1  as  well  as  their  compositions  and  the  results  of  the  merges  are 
one-to-one.  Thus  the  problem  lies  in  the  relationships  between  the  versions,  and  is 
unlikely  to  be  preventable  via  localized  restrictions  that  can  be  applied  to  each  of  the 
versions  independently. 

The  circumstances  where  this  interference  effect  shows  up  are  complex  and  not 
very  intuitive.  For  example,  one  case  where  the  interference  effect  shows  up  without 
producing  any  local  or  global  conflicts  is  when  there  is  some  input  value  x  for  the 
front  end  for  which  the  first  change  does  not  affect  either  the  output  of  the  front  end 
(AGO  =  Si(*))  or  the  output  of  the  entire  system  (/:(/i(jc))=  g2(.  g\(x))),  and  the 
second  change  transforms  the  output  of  the  front  end  into  a  value  affected  by  the  first 
change  to  the  back  end  but  not  affected  by  the  second  change  to  the  back  end 
(/:(/iiOO)*  g2(hl(x))  =  h2dhU))). 

A  concrete  example  of  this  is  a  simple  text  formatter  composed  of  two  parts.  The 
front  end  determines  which  words  go  on  each  line,  and  the  base  version  puts  as  many 
words  as  will  fit.  The  back  end  adds  extra  space  between  the  words,  and  the  base  ver- 
sion adds  enough  space  to  make  the  right  margin  even  on  every  line  except  the  last 
line  of  a  paragraph.  The  first  change  affects  only  the  back  end,  which  is  changed  to 
adjust  the  right  margin  of  the  last  line  of  a  paragraph  in  those  cases  where  the  space 
left  at  the  end  of  the  line  is  strictly  less  than  a  given  tolerance  T,  where  T  >  1.  The 
second  change  affects  only  the  front  end,  which  is  changed  so  that  if  the  space  left  on 
a  line  when  no  more  words  from  the  following  text  will  fit  is  greater  than  the  space 
left  on  the  previous  line  plus  the  length  of  the  last  word  on  the  previous  line,  then  the 
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last  word  of  the  previous  line  is  moved  up  to  the  current  line.  The  interference  effect 
will  show  up  for  an  input  where  the  space  left  on  the  last  line  of  the  paragraph  is 
exactly  equal  to  the  tolerance  T,  the  previous  line  is  completely  full,  and  the  last  word 
on  the  previous  line  is  one  character  long.  If  we  merge  the  two  changes  in  a  single 
global  operation  then  the  merged  version  will  move  up  the  last  word  of  the  previous 
line  and  will  not  adjust  the  right  margin  of  the  last  line.  If  we  merge  the  two  changes 
in  isolation  and  combine  the  results,  then  the  resulting  program  will  adjust  the  right 
margin  of  the  last  line  in  addition  to  moving  up  the  last  word  of  the  previous  line. 
The  two  results  are  clearly  different. 

Also  note  that  it  is  possible  for  the  true  merge  of  the  compositions  to  contain  a 
conflict  even  if  the  independent  merges  of  the  changes  to  corresponding  subfunctions 
are  conflict-free  (compare  the  results  of  example  1  for  x  =  4).  Approximate  change 
merging  methods  must  be  sale  to  be  practically  useful:  they  must  never  silently  turn  a 
real  conflict  into  a  proper  (but  incorrect)  result,  although  they  may  occasionally  report 
potential  conflicts  that  are  not  really  there.  This  implies  that  unrestricted  changes  to 
different  subprograms  cannot  in  practice  be  merged  independently,  and  that  interpro- 
cedural  analysis  is  necessary  for  reliable  change  merging.  Thus  correct  divide  and 
conquer  methods  for  unrestricted  change  merging  cannot  exist,  at  least  relative  to 
modularizations  based  on  functional  decomposition. 

This  is  quite  unwelcome  news  for  those  concerned  with  the  evolution  of  large 
software  systems,  because  functional  decomposition  is  the  modularization  principle 
underlying  many  widely  used  approaches  to  systems  analysis  and  software  design, 
such  as  structured  analysis.  We  discuss  the  implications  of  this  for  the  practitioner  at 
the  end  of  this  section,  after  examining  in  more  detail  the  conditions  under  which 
change  merging  can  and  cannot  be  performed  independently  for  the  components  of 
functional  decompositions. 

Some  weaker  distributive  properties  related  to  change  merging  do  hold.  The  fol- 
lowing calculation  shows  that  functional  composition  distributes  over  the  program 
merge  operation  from  the  right. 

Property  P3 

(f[g]h)0c  =(/!+  /  h  +  Jh)9c 

=  (  /  o  c)(~g  o  c )  +  (  /  o  c )(  h  o  c )  +  (~g  0  c )(  h  0  c ) 

=  (/  o  c)[g  o  c](  ft  0  c) 
The  derivation  uses  the  fact  that  ~g  Qc  =  "JTZ-.  This  property  says  that  the  result  of 
merging  two  changes  is  the  same,  independently  of  whether  the  inputs  to  the  module 
that  has  been  changed  are  supplied  directly  or  come  from  another  module.  This  is 
what  most  programmers  would  expect.  We  note  that  composition  on  the  right  may 
mask  some  conflicts  in  f[g]  ft,  because  the  range  of  c  may  be  a  strict  subset  of  the 
domains  of  /,  g,  and  h  that  may  not  include  some  potential  conflicts  between  those 
functions. 

Functional  composition  does  not  always  distribute  over  program  merging  from  the 
left,  but  half  of  a  distributive  law  is  possible  for  conflict-free  monotonic  functions  on 
primitive  domains  restricted  to  conflict-free  portions  of  the  input  space.  The  restriction 
to  monotonic  functions  is  reasonable  because  every  computable  function  is  monotonic. 
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The  restriction  to  conflict-tree  functions  is  also  reasonable  because  conflicts  can  be 
introduced  only  by  a  process  of  combining  changes  that  operates  in  an  extended  syn- 
tactic domain:  for  every  programming  language  we  have  seen,  every  program  that  fol- 
lows the  syntax  rules  of  the  programming  language  is  conflict-free.  The  restriction  to 
conflict-free  inputs  is  reasonable  because  there  is  no  way  to  create  self-contradictory 
input  values  on  real  computer  systems.  The  restriction  to  primitive  domains  is  less 
desirable,  but  it  is  necessary,  as  we  demonstrate  below.  We  start  with  a  definition 
summarizing  characterizations  of  semantic  conflicts  from  Section  3  and  a  lemma. 
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Definition.  An  element  x  of  a  primitive  domain  (Section  3.2.1)  is  conflict-free  if  and 
only  if  x  C  a  for  some  atom  a.  A  tuple  x  e  Dx  x  D2  is  conflict-free  if  and  only  if  jc,  and 
x2  are  conflict-free.  An  element  x  <=  Dx  -  D2  of  an  extended  sum  domain  (encoded  as  a 
cross  product)  is  conflict-free  if  and  only  if  xx  and  x2  are  conflict-free  and  either  xx  =  0 
or  x2  =  0.  A  function  f:Dx  -*  D2  is  conflict-free  if  and  only  if  fix)  is  conflict-free  for 
all  conflict-free  xeD{.  A  set  s  e  P(D)  is  conflict-free  if  and  only  if  x  is  conflict-free 
for  all  x  e  s,  where  P(D)  can  denote  either  the  Hoare  power  domain  construction  or  the 
Smyth  power  domain  construction  (Section  3.3.1). 

Lemma  2.  If  /.  g:D1-*D2  are  restricted  to  the  conflict-free  portion  of  D:, 
c:D2->D}  is  monotonic,  /  is  conflict-free  and  D2  is  a  primitive  domain  then 
(c  0  f)ic  0  g)  ~  (c  o  /)(c  0  1). 

Proof: 

Since  /  is  conflict-free,  fix)  is  conflict-free  for  all  conflict-free  x  e  £>,. 
Let  xeDx.  Then  fix)  C  a  for  some  atom  a,  since  D2  is  a  primitive  domain. 
Case  l:al   gix).  Then  f(x)Z   gix). 

So  c(fix))-c(  g(x))  and  c(f(x))c(  g(x))  =  0  1  cifix))cCg(x)). 
Case  2:  a  g(x)  =  0.  Then  fix)  gix)  =  »  since  fix)  gix)  Z  a  gix). 
Then  f(x)Z  ~g(x),  c(f(x))Z  cCgix)),  and  c(f(x))  =  cifix))cCgix)), 
so  ci  fix  ))c(  gix  ))Z  c(f  (x ))  =  c  ( /  ix  ))c  i-gix )). 
Since  a  is  an  atom,  cases  1  and  2  cover  all  possibilities. 
So  (c  o  f)ic  o  «)l(c,  /)(c  o  1)  since  c(/u))c(  g(j;))  C  c(/(jc))c(7(x))  for  all  x. 

Theorem  2.  If  /,  g.  h:Dx->D2  are  restricted  to  the  conflict-free  poruon  of  D{, 
c:  D2  ->  D3  is  monotonic,  /  and  h  are  conflict-free,  and  D:  is  a  primitive  domain  then 
ic  o  f)[c  o  i'Kc  0h)Zc  „(f[g]  h) 

Proof: 

o    f)[C    o    5l(C    o  /O 

Definition  of  .  [  .  ]  . 
Lemma  2 
Monotonicity  of  c 
Monotonicity  of  c 
Definition  of  .  [  .  ]  . 

The  following  example  shows  that  the  inequality  in  theorem  2  is  sometimes  strict. 


iC    o    f)[C    o    g]iC    o  ll) 

=  (C    o    /XC    o     ^)+(Co/  KC    o     11)  +  if    o    g)(C    o 

ft) 

C(Co/XCo7)+(Co/  )(C   o    ft)  +  iC  a  1)(C   0 

ft) 

Z  c  o  (/^)  +  c  o  (/  /i)  +  c  o  (1  ft) 

lc,(/1+/A+]/i) 

=  c  oif[g]h) 

-)-> 


Example  2. 

f  g  h  c(l)      c(2)      c(3) 

12  3  4  4  5 

c(f)[c(g)]c(h)  =  4[4]5  =  5 

c(f[g]h)==c(l[2]3)  =  c(lu3)  =  c(l)uc(3)  =  4u5  *  5 

Together  with  property  P3,  theorem  2  says  that  if  two  changes  affect  only  one  module 
of  a  system  and  we  merge  the  two  changes  to  the  module  in  isolation,  then  the  result 
of  replacing  the  original  module  with  the  doubly-changed  one  in  the  system  is  con- 
sistent with  the  (ideal)  result  of  merging  the  corresponding  versions  of  the  entire  sys- 
tem. The  fact  that  theorem  2  is  an  inclusion  rather  than  an  equality  means  that  some 
conflicts  that  appear  when  merging  the  changes  to  the  module  in  isolation  might  not 
really  be  conflicts  if  the  change  merging  operation  were  expanded  to  act  on  the  context 
c  (the  system  in  which  the  module  is  embedded)  in  addition  to  the  base  version  g  and 
the  two  modified  versions  /  and  h  of  the  impacted  module.  This  seems  natural 
enough,  since  the  context  c  is  free  to  map  two  incompatible  intermediate  values  fix) 
and  h(x)  into  the  same  value. 

Theorem  2  behaves  like  a  partial  correctness  result  even  though  the  inclusion 
appears  to  go  in  the  wrong  direction,  because  it  is  not  possible  in  practice  (under  the 
hypotheses  of  the  theorem)  for  the  left  hand  side  to  be  undefined  and  the  right  hand 
side  to  be  a  proper  value  unless  the  isolated  merge  /  [  g]  h  produces  a  conflict.  We 
can  see  this  as  follows.  A  strict  inequality  in  theorem  2  is  possible  at  a  given  point  in 
D ,  only  if  the  values  of  / ,  g,  and  h  are  all  distinct,  because  c(f[g]g)=  c  ( / )  = 
c(f)[c(  g)]c(  g)  and  c(f[g]f)=  c(/)  =  c(f)[c(g)]c(f).  If  c  is  computable  we  must 
have  c(_)=  _  except  when  c  is  a  constant  function,  and  in  that  case  theorem  2 
becomes  an  equality.  This  gives  us  c(i.[g]h)  =  c(  h)  =  i  [c ( g)]c ( h)  = 
c(  _  )[c(  g)]c(  h).  Thus  strict  inequality  is  possible  only  when  the  values  of  /,  g,  and 
h  are  all  distinct  and  /  *  i  *  h,  and  in  that  case  the  value  of  f[g]h  at  the  given 
point  represents  a  semantic  conflict,  since  D2  is  a  primitive  domain. 

Most  programmers  would  expect  these  properties  to  be  true  in  general.  However, 
this  is  not  the  case:  we  have  proved  theorem  2  only  when  the  intermediate  domain  D2 
is  primitive,  and  it  turns  out  that  the  theorem  does  not  hold  if  we  remove  that  restric- 
tion. To  see  that  theorem  2  need  not  hold  if  we  relax  the  requirement  that  D2  is  a 
primitive  data  domain,  consider  the  following  example,  in  which  Dx  and  £>3  are  primi- 
tive domains  containing  numbers  and  D2  contains  6-tuples  of  numbers. 

Example  3. 

Tj  =  /(2)  =  [2.  2.   i  ,  1 ,   i  .  2]  c(T,)  =  2 

T2  =  g(2)  =  [2,   i  ,  Z  i  .  2.  i  ]  cfl\)  =  2 

T3  =   ft(2)  =  [1,2,2,2.  i  ,   i  ]  c(T3)  =  2 

T,  =  /(2)[  g(2)]  /t(2)  =  [2.  2.  2.  1 .  1 ,  i  ]         c(T4)  =  3*2  =  cOlO[c(T£]c(J£ 

In  this  example  the  tuples  T[  -  T4  are  all  incomparable,  so  that  monotonicity  does  not 
impose  any  relationships  between  their  images  under  the  function  c.    The  fact  that 
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theorem  2  need  not  hold  for  all  conflict-free  monotonic  functions  may  be  even  more 
surprising  than  Example  1,  because  it  shows  that  there  can  be  interference  between 
functional  composition  and  a  single  program  change  that  produces  a  conflict-free  result 
when  carried  out  in  isolation.  This  can  happen  if  the  intermediate  domain  D2  contains 
partial  functions  or  partial  data  structures  (which  are  realized  via  lazy  evaluation  in 
some  functional  programming  languages).  Although  the  computations  in  Example  3 
are  somewhat  unusual,  the  function  c  can  be  realized  (via  several  applications  of  a 
non-deterministic  operation  that  evaluates  two  expressions  in  parallel  and  returns  the 
value  of  the  first  one  that  terminates). 

Some  positive  results  are  also  possible  for  the  simpler  subproblem  of  combining 
compatible  extensions  to  a  program  [1].  The  simplification  that  occurs  when  merging 
compatible  extensions  is  described  by  lemma  3. 

Lemma  3.    If  g  Z  /  and  g  Z   h  then  /  [  g]  h  =  f  +  h. 


Proof: 


f{g]h  =  f~g  +  f  g  h  +  H  h 
=  f~g+fgh+fgh  +  ~gh 

=  fCg+  g)  +  (g  +  1)h 
=  /+  h 


since   g  =  f  g  =  g  h  =  /  g  h 


The  following  distributivity  properties  hold  for  the  special  case  of  compatible  exten- 
sions. 

Property  P4 

(/  0c)  +  (g0c)  =  (/  +  h)0c 

Property  P5 

(c  o  /)  +  (c  o  h)  r  c  o  (/  +  h) 

Property  P4  follows  from  the  definition  of  +  on  function  spaces.  Property  P5  follows 
from  the  monotonicity  of  c  (all  computable  functions  are  monotonic),  and  becomes  an 
equality  for  additive  (see  [25]  p.  105)  functions  c .  The  special  case  of  additive  func- 
tions has  some  practical  interest:  functions  computed  by  conflict-free  subprograms  on 
primitive  data  domains  are  additive.  The  restriction  to  primitive  domains  (which  also 
appears  in  theorem  2)  holds  for  subsets  of  programming  languages  that  do  not  allow 
subprograms  to  be  passed  as  parameters,  do  not  support  partially  defined  data  struc- 
tures, and  pass  all  parameters  by  value  or  by  reference  (i.e.  no  higher  order  functions, 
lazy  evaluation,  or  call  by  name). 

We  can  get  half  of  a  distributivity  law  for  compatible  extensions  from  properties 
P4  and  P5. 

Theorem  3.    If  g2  C  fy  h-i  and  g\Z  f  x,  hx  then 
(/2./1X&.  8iKh2o  hOgifzlgdfyoifdgilhd. 

Proof: 
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Suppose  g2  Z  f2,  h2  and  gx~  /lt  h\. 

Then  g2(gi(x))C  gz(fx{x))Z  /;(/,(*))  for  all  x,  so  #:  0  ?,:  /20A. 

Similarly  g2  o  Si  Q   ^  A,. 

/20  /it  g2  o  gi]  /i2  0  hx  =  (/2  o  /i)  +  (  ft2o  h\)  Lemma  3 

Q  (flo  /])+  (/:  o    //i)  +  (  /j2  o  /i)  +  (  &2  o    /ji) 

Q  /:  o  (/1  +  /M  +  /i2  o  (/1  +  M  Property  P5 

=  (/:+  A2)0(/i  +  fy)  Property  P4 

-(filgzifh)  o(fiig{lhi)  Lemma  3 

Theorem  3  can  serve  as  the  basis  for  an  approximate  method  for  merging  compatible 
extensions  that  impact  different  modules  of  a  system  that  are  connected  by  data  flows. 
This  covers  a  situation  in  which  methods  based  on  program  slicing,  such  as  [12], 
would  always  report  a  conflict.  Since  theorem  3  is  an  inclusion  rather  than  an  equa- 
tion, such  a  method  may  report  some  extraneous  conflicts  (see  Example  2  and  the  fol- 
lowing discussion). 

Our  results  impact  current  software  development  practices  in  some  environments. 
Common  sense  suggests  that  a  change  to  a  module  can  affect  all  of  the  other  modules 
that  can  receive  data  from  the  modified  module.  However,  in  informal  conversations, 
several  practicing  software  engineers  have  described  real  projects  where  different  peo- 
ple were  routinely  assigned  to  make  concurrent  changes  to  modules  with  apparently 
unrelated  functions,  and  the  results  of  such  updates  were  combined  simply  by  linking 
the  new  versions  of  both  modules  into  the  system  after  both  updates  appear  to  have 
been  implemented  correctly.  This  practice  appears  to  be  based  on  belief  in  the 
(incorrect)  distributivity  property  marked  with  a  (?)  at  the  beginning  of  this  section,  or 
on  the  unquestioned  assumption  that  if  both  engineers  did  their  job  correctly,  then  all 
should  be  well.  The  results  of  this  section  show  that  this  assumption  is  not  always 
sound,  and  that  the  situation  is  far  from  simple  in  the  general  case. 

Example  1  shows  that  the  results  of  combining  changes  to  several  different 
modules  that  are  correct  for  each  module  in  isolation  can  produce  incorrect  results 
when  the  modules  are  assembled  into  a  system  in  such  a  way  that  the  output  of  one 
changed  module  can  reach  the  input  of  another  changed  module.  More  surprisingly, 
two  changes  to  the  same  module  that  are  consistent  and  produce  correct  results  when 
the  module  is  considered  in  isolation  can  produce  an  incorrect  system-level  result  when 
the  module  is  embedded  in  a  larger  system  where  nothing  else  has  been  changed 
(example  3),  although  the  conditions  under  which  this  can  occur  are  rather  exotic. 

Some  special  cases  where  independent  changes  can  be  combined  in  isolation  and 
then  can  be  safely  embedded  in  a  larger  system  are  identified  in  theorems  2  and  3.  In 
other  cases,  when  changes  are  combined,  all  modules  whose  inputs  can  be  affected  by 
the  outputs  of  the  changed  modules  must  be  checked  together  to  establish  the  mutual 
correctness  of  the  combined  changes.  The  correctness  of  the  combined  changes  must 
be  checked  explicidy,  in  addition  to  checking  the  correctness  of  each  change  in  isola- 
tion, since  in  the  general  case  the  combination  can  be  incorrect  even  if  each  individual 
change  produces  correct  results  when  considered  in  isolation  form  the  other  changes. 
The  required  check  requires  interprocedural  analysis  that  can  span  large  subsets  of  the 
system  even  if  only  a  few  modules  of  the  system  have  actually  been  changed.    Such 
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checking  can  be  quite  expensive  if  it  is  to  be  done  manually.  This  consideration  pro- 
vides some  support  for  test  strategies  that  use  program  slicing  to  determine  the  impact 
of  a  change  and  to  guide  the  selection  of  test  data. 

It  is  natural  to  ask  why  this  problem  has  not  been  noticed  before,  if  it  really  is 
potentially  serious.  One  relevant  point  is  that  the  desired  distributivity  property  is 
almost  true,  in  the  sense  that  it  was  fairly  difficult  to  find  counterexamples.  We  suc- 
ceeded in  doing  so  only  by  explicitly  analyzing  the  merging  formula  and  several  failed 
attempts  to  prove  that  the  property  was  true.  Thus  failures  due  to  this  mechanism 
might  not  be  easy  to  detect  using  small  sets  of  test  cases.  Another  point  is  that  large 
systems  in  practice  are  subject  to  failures  that  do  not  have  clearly  understood  causes: 
"integration  problems"  during  system-level  testing  are  common,  as  is  "software  rot" 
that  gradually  appears  as  systems  go  through  a  long  series  of  changes.  Although  these 
problems  are  undoubtably  due  in  part  to  human  error,  the  counterexamples  to  the  dis- 
tributivity law  suggest  that  there  may  be  other  factors  involved  as  well.  At  the  current 
state  of  the  art  it  would  take  a  tedious  experimental  effort  to  accurately  gauge  how 
important  these  effects  are  in  actual  practice.  This  should  become  easier  after  reliable 
tools  for  semantically-based  change  merging  are  developed  that  can  adequately  treat  at 
least  one  programming  language  that  is  used  in  large  software  development  and 
maintenance  activities. 

It  is  also  natural  to  ask  what  practitioners  can  do  to  avoid  merging  problems 
before  reliable  change  merging  tools  become  available.  Our  results  indicate  that  in  the 
general  case  changes  cannot  be  combined  reliably  without  including  the  context  of  the 
change.  If  accurate  behavioral  specifications  for  submodules  are  available,  then  these 
can  be  used  to  break  some  of  the  dependency  chains,  thus  reducing  the  size  of  the  part 
of  the  context  that  must  be  considered  when  implementing  and  checking  a  change 
[15].  This  enables  a  higher  degree  of  concurrency  between  the  work  of  designers 
working  on  different  changes  without  giving  up  serializability  of  the  updates.  In  such 
an  approach  each  change  must  be  checked  with  respect  to  only  one  context  (the  one 
defined  by  the  serialization  order,  and  identified  as  the  primary  input  of  the  top  level 
step  in  [15])  because  each  change  becomes  part  of  the  context  for  the  next  change  in 
the  serialization  order. 

5.   Conclusions  and  Future  Work 

We  have  provided  a  characterization  of  the  semantic  properties  of  an  operation 
for  combining  changes  to  software  objects,  and  have  shown  that  the  formal  model  has 
some  of  the  properties  that  we  would  intuitively  expect.  This  characterization  is 
independent  of  the  programming  language  in  which  the  software  objects  are  described, 
and  can  be  applied  in  many  contexts.  We  note  that  the  HPR  algorithm  [12]  is  correct 
with  respect  to  our  characterization  for  the  cases  in  which  it  does  not  report  any 
conflicts.  One  advantage  of  our  formal  model  is  that  it  provides  a  natural  representa- 
tion for  conflicts  in  the  cases  where  the  given  changes  cannot  be  consistently  com- 
bined. The  model  can  be  applied  to  requirements  and  specifications  in  addition  to  pro- 
grams, if  we  accept  the  view  that  a  specification  is  a  predicate  that  characterizes  the 
set  of  all  acceptable  system  behaviors,  although  the  details  of  this  are  not  explored  in 
the  current  paper. 
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In  related  work  [6]  we  have  applied  our  model  of  the  change  combination  process 
to  propose  a  new  method  for  integrating  changes  to  PSDL  programs.  PSDL  is  a 
language  for  prototyping  large,  real-time  systems,  which  is  based  on  an  enhanced  data 
flow  model  of  computation  [14].  This  language  includes  features  for  expressing  con- 
currency and  real-time  constraints.  A  formal  semantics  of  PSDL  can  be  found  in  [13]. 
An  initial  version  of  a  method  for  combining  changes  to  PSDL  programs  has  been 
developed  [6,8].  We  are  also  investigating  the  application  of  this  framework  to  the 
development  of  program  transformations  that  change  the  semantics  of  a  program  in  a 
disciplined  way  [4].  Such  transformations  are  important  in  software  evolution,  and 
form  a  complement  to  the  meaning-preserving  transformations  that  are  used  in  imple- 
menting executable  specification  languages  and  in  program  optimization. 

The  results  presented  in  this  paper  establish  a  clear  correctness  criterion  for 
software  change  merging.  Much  more  work  remains  to  be  done  before  automated 
change  merging  can  be  realized  in  practice.  In  particular,  the  fact  that  the  program 
merging  operation  does  not  distribute  over  functional  composition  (see  Section  4.4) 
implies  that  changes  to  "independent"  modules  cannot  in  general  be  processed  indepen- 
dently. This  may  provide  some  objective  support  for  the  common  belief  that  software 
maintenance  is  difficult  to  do,  and  suggests  that  significant  computational  capacity  may 
be  required  to  reliably  combine  changes  to  large  software  systems.  Section  4.4  deter- 
mines some  of  the  conditions  under  which  changes  to  subfunctions  can  be  merged 
independendy. 

Since  the  exact  solution  to  the  program  merging  problem  is  undecidable,  future 
work  should  explore  the  tradeoff  between  computational  efficiency  and  the  size  of  the 
subspace  for  which  an  algorithm  can  produce  exact  results.  We  would  like  to  have 
reliable  approximation  algorithms  that  produce  few  spurious  warnings  and  succeed  in 
finding  conflict-free  merges  in  most  of  the  cases  where  they  exist.  An  initial  step  in 
this  direction  has  been  based  on  program  dependency  graphs  [12].  A  calculus  for 
deriving  change  merges  with  fewer  spurious  conflicts  and  the  capability  to  successfully 
merge  speedup  transformations  with  other  changes  is  described  in  [2].  More  work  is 
needed  to  develop  representations  of  programs  that  can  support  accurate  program 
merge  algorithms  with  wide  coverage.  The  crux  of  the  problem  is  to  recognize 
equivalent  program  fragments  that  are  not  identical.  Normal  forms  and  transformation 
technology  [9]  are  likely  to  be  important  for  this  aspect  of  the  problem. 
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